home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group G. Malkin
- Request for Comments: 1393 Xylogics, Inc.
- January 1993
-
-
- Traceroute Using an IP Option
-
- Status of this Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. Discussion and suggestions for improvement are requested.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
- Abstract
-
- Traceroute serves as a valuable network debugging tool. The way in
- which it is currently implemented has the advantage of being
- automatically supported by all of the routers. It's two problems are
- the number of packets it generates and the amount of time it takes to
- run.
-
- This document specifies a new IP option and ICMP message type which
- duplicates the functionality of the existing traceroute method while
- generating fewer packets and completing in a shorter time.
-
- Table of Contents
-
- 1. Traceroute Today . . . . . . . . . . . . . . . . . . . . . 2
- 2. Traceroute Tomorrow . . . . . . . . . . . . . . . . . . . . 2
- 2.1 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . 2
- 2.2 IP Traceroute option format . . . . . . . . . . . . . . . . 3
- 2.3 ICMP Traceroute message format . . . . . . . . . . . . . . 4
- 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.1 Hop Counts . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2 Destination Node Operation . . . . . . . . . . . . . . . . 6
- 3.3 Router Operation . . . . . . . . . . . . . . . . . . . . . 6
- 4. References . . . . . . . . . . . . . . . . . . . . . . . . 7
- 5. Security Considerations . . . . . . . . . . . . . . . . . . 7
- 6. Author's Address . . . . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
- Malkin [Page 1]
-
- RFC 1393 Traceroute January 1993
-
-
- 1. Traceroute Today
-
- The existing traceroute operates by sending out a packet with a Time
- To Live (TTL) of 1. The first hop then sends back an ICMP [1] error
- message indicating that the packet could not be forwarded because the
- TTL expired. The packet is then resent with a TTL of 2, and the
- second hop returns the TTL expired. This process continues until the
- destination is reached. The purpose behind this is to record the
- source of each ICMP TTL exceeded message to provide a trace of the
- path the packet took to reach the destination.
-
- The advantage of this algorithm, is that every router already has the
- ability to send TTL exceeded messages. No special code is required.
- The disadvantages are the number of packets generated (2n, where n is
- the number of hops), the time it takes to duplicate all the nearer
- hops with each successive packet, and the fact that the path may
- change during this process. Also, this algorithm does not trace the
- return path, which may differ from the outbound path.
-
- 2. Traceroute Tomorrow
-
- The proposed traceroute would use a different algorithm to achieve
- the same goal, namely, to trace the path to a host. Because the new
- traceroute uses an ICMP message designed for the purpose, additional
- information, unavailable to the original traceroute user, can be made
- available.
-
- 2.1 Basic Algorithm
-
- A new IP Traceroute option will be defined. The presence of this
- option in an ICMP Echo (or any other) packet, hereinafter referred to
- as the Outbound Packet, will cause a router to send the newly defined
- ICMP Traceroute message to the originator of the Outbound Packet. In
- this way, the path of the Outbound Packet will be logged by the
- originator with only n+1 (instead of 2n) packets. This algorithm
- does not suffer from a changing path and allows the response to the
- Outbound Packet, hereinafter refered to as the Return Packet, to be
- traced (provided the Outbound Packet's destination preserves the IP
- Traceroute option in the Return Packet).
-
- The disadvantage of this method is that the traceroute function will
- have to be put into the routers. To counter this disadvantage,
- however, is the fact that this mechanism may be easily ported to a
- new IP version.
-
-
-
-
-
-
-
- Malkin [Page 2]
-
- RFC 1393 Traceroute January 1993
-
-
- 2.2 IP Traceroute option format
-
- 0 8 16 24
- +-+-+-+-+-+-+-+-+---------------+---------------+---------------+
- |F| C | Number | Length | ID Number |
- +-+-+-+-+-+-+-+-+---------------+---------------+---------------+
- | Outbound Hop Count | Return Hop Count |
- +---------------+---------------+---------------+---------------+
- | Originator IP Address |
- +---------------+---------------+---------------+---------------+
-
- F (copy to fragments)
-
- 0 (do not copy to fragments)
-
- C (class)
-
- 2 (Debugging & Measurement)
-
- Number
-
- 18 (F+C+Number = 82)
-
- ID Number
-
- An arbitrary number used by the originator of the Outbound Packet
- to identify the ICMP Traceroute messages. It is NOT related to
- the ID number in the IP header.
-
- Originator IP Address
-
- The IP address of the originator of the Outbound Packet. This is
- needed so the routers know where to send the ICMP Traceroute
- message for Return Packets. It is also needed for Outbound
- Packets which have a Source Route option.
-
- Outbound Hop Count (OHC)
-
- The number of routers through which the Outbound Packet has
- passed. This field is not incremented by the Outbound Packet's
- destination.
-
- Return Hop Count (RHC)
-
- The number of routers through which the Return Packet has passed.
- This field is not incremented by the Return Packet's destination.
-
-
-
-
-
- Malkin [Page 3]
-
- RFC 1393 Traceroute January 1993
-
-
- 2.3 ICMP Traceroute message format
-
- 0 8 16 24
- +---------------+---------------+---------------+---------------+
- | Type | Code | Checksum |
- +---------------+---------------+---------------+---------------+
- | ID Number | unused |
- +---------------+---------------+---------------+---------------+
- | Outbound Hop Count | Return Hop Count |
- +---------------+---------------+---------------+---------------+
- | Output Link Speed |
- +---------------+---------------+---------------+---------------+
- | Output Link MTU |
- +---------------+---------------+---------------+---------------+
-
- Type
-
- 30
-
- Code
-
- 0 - Outbound Packet successfully forwarded
- 1 - No route for Outbound Packet; packet discarded
-
- Checksum
-
- The 16 bit one's complement of the one's complement sum of all 16
- bit words in the header. For computing the checksum, the checksum
- field should be zero.
-
- ID Number
-
- The ID Number as copied from the IP Traceroute option of the
- packet which caused this Traceroute message to be sent. This is
- NOT related to the ID number in the IP header.
-
- Outbound Hop Count
-
- The Outbound Hop Count as copied from the IP Traceroute option of
- the packet which caused this Traceroute message to be sent.
-
- Return Hop Count
-
- The Return Hop Count as copied from the IP Traceroute option of
- the packet which caused this Traceroute message to be sent.
-
-
-
-
-
-
- Malkin [Page 4]
-
- RFC 1393 Traceroute January 1993
-
-
- Output Link Speed
-
- The speed, in OCTETS per second, of the link over which the
- Outbound/Return Packet will be sent. Since it will not be long
- before network speeds exceed 4.3Gb/s, and since some machines deal
- poorly with fields longer than 32 bits, octets per second was
- chosen over bits per second. If this value cannot be determined,
- the field should be set to zero.
-
- Output Link MTU
-
- The MTU, in bytes, of the link over which the Outbound/Return
- Packet will be sent. MTU refers to the data portion (includes IP
- header; excludes datalink header/trailer) of the packet. If this
- value cannot be determined, the field should be set to zero.
-
-
- 3. Protocol
-
- The Outbound Packet which is used to carry the IP Traceroute option
- should use no special Type Of Service (TOS) or Precedence, unless the
- purpose is to trace the path of packets with special TOS or
- Precedence values.
-
- The TTL of the Outbound Packet should be set to the default value
- specified in "Assigned Numbers" [2].
-
- 3.1 Hop Counts
-
- The hop counts ultimately provide information on the length of the
- outbound and return paths to the destination. They also provide a
- means of determining whether or not any ICMP Traceroute messages have
- been lost. For example, if a Traceroute message with an OHC of 4 is
- followed by a message with an OHC of 6, then the the message with an
- OHC of 5 was lost. This is why simply counting Traceroute messages
- is not sufficient for determining path length.
-
- The originator of the Outbound Packet should set the OHC to zero and
- the RHC to 0xFFFF. 0xFFFF is a special value which indicates to
- routers that the packet is an Outbound Packet rather than a Return
- Packet (which begins with an RHC of zero).
-
- It is important to note that the Traceroute hop counts are NOT
- related to the IP TTL. A hop count should only be incremented when
- an ICMP Traceroute message is sent.
-
-
-
-
-
-
- Malkin [Page 5]
-
- RFC 1393 Traceroute January 1993
-
-
- 3.2 Destination Node Operation
-
- When a node receives an Outbound Packet with an IP Traceroute option,
- the Return Packet, if such is required (e.g., ICMP Echo
- Request/Reply), should also carry that option. The values in the ID
- Number, OHC, and Originator Address fields should be copied into the
- Return Packet. The value of the RHC field should be set to zero.
-
- The destination should NOT increment any hop counts or send any ICMP
- Traceroute messages.
-
- 3.3 Router Operation
-
- When a router forwards a packet with an IP Traceroute option, it
- should send an ICMP Traceroute message to the host in the Originator
- IP Address field of the option. If the value of the RHC field is
- 0xFFFF then the packet is an Outbound Packet and the OHC should be
- incremented; otherwise, the RHC field should be incremented. The
- Traceroute message should reflect the incremented hop count. The
- Output Link Speed field should be set to the speed, in OCTETS per
- second, of the link over which the Outbound/Return Packet will be
- sent (e.g., 1,250,000 for an Ethernet) or zero if the output link
- speed cannot be determined. The Output Link MTU field should be set
- to the MTU of the link over which the Outbound/Return Packet will be
- sent or zero if the MTU cannot be determined.
-
- The Outbound/Return Packet should be forwarded as though the
- Traceroute option did not exist; that is, it should take the same
- path to the destination as an optionless packet.
-
- The ICMP Traceroute message should have the same TOS and Precedence
- values as the Outbound/Return Packet. The TTL should be set to the
- default defined in "Assigned Numbers".
-
- The ICMP Traceroute message should not carry the IP Traceroute
- option.
-
- If the Outbound Packet cannot be forwarded, the ICMP Traceroute
- message should have a Code value of 1. If the Return Packet cannot
- be forwarded because there is no route, then there is no need to send
- a Traceroute message since it could not be forwarded either.
-
-
-
-
-
-
-
-
-
-
- Malkin [Page 6]
-
- RFC 1393 Traceroute January 1993
-
-
- 4. References
-
- [1] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
- USC/Information Sciences Institute, September 1981.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
-
- 5. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
- 6. Author's Address
-
- Gary Scott Malkin
- Xylogics, Inc.
- 53 Third Avenue
- Burlington, MA 01803
-
- Phone: (617) 272-8140
- EMail: gmalkin@Xylogics.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Malkin [Page 7]
-
-